Functional programming abstractions for weakly consistent systems

In recent years, there has been a wide-spread adoption of both multicore and cloud computing. Traditionally, concurrent programmers have relied on the underlying system providing strong memory consistency, where there is a semblance of concurrent tasks operating over a shared global address space. However, providing scalable strong consistency guarantees as the scale of the system grows is an increasingly difficult endeavor. In a multicore setting, the increasing complexity and the lack of scalability of hardware mechanisms such as cache coherence deters scalable strong consistency. In geo-distributed compute clouds, the availability concerns in the presence of partial failures prohibit strong consistency. Hence, modern multicore and cloud computing platforms eschew strong consistency in favor of weakly consistent memory, where each task\u27s memory view is incomparable with the other tasks. As a result, programmers on these platforms must tackle the full complexity of concurrent programming for an asynchronous distributed system. ^ This dissertation argues that functional programming language abstractions can simplify scalable concurrent programming for weakly consistent systems. Functional programming espouses mutation-free programming, and rare mutations when present are explicit in their types. By controlling and explicitly reasoning about shared state mutations, functional abstractions simplify concurrent programming. Building upon this intuition, this dissertation presents three major contributions, each focused on addressing a particular challenge associated with weakly consistent loosely coupled systems. First, it describes A NERIS, a concurrent functional programming language and runtime for the Intel Single-chip Cloud Computer, and shows how to provide an efficient cache coherent virtual address space on top of a non cache coherent multicore architecture. Next, it describes RxCML, a distributed extension of MULTIMLTON and shows that, with the help of speculative execution, synchronous communication can be utilized as an efficient abstraction for programming asynchronous distributed systems. Finally, it presents QUELEA, a programming system for eventually consistent distributed stores, and shows that the choice of correct consistency level for replicated data type operations and transactions can be automated with the help of high-level declarative contracts

Acquired rifampicin resistance in thrice-weekly antituberculosis therapy: impact of HIV and antiretroviral therapy

Risk factors for acquired rifampicin resistance (ARR) among tuberculosis patients on thrice-weekly antituberculosis therapy were baseline isoniazid resistance and HIV. Among HIV-infected patients, higher mycobacterial burden and lower CD4 count, but not highly active antiretroviral therapy, were significantly associated with ARR. Background: Risk factors for acquired rifampicin resistance (ARR) in human immunodeficiency virus (HIV)/tuberculosis coinfection, in the highly active antiretroviral therapy (HAART) era, needs evaluation. We studied the impact of HIV and HAART on ARR among patients taking thrice-weekly antituberculosis therapy. Methods: This cross-protocol analysis included patients with newly diagnosed, rifampicin-susceptible pulmonary tuberculosis, with and without HIV, enrolled in clinical trials (who took >80% of medication) at the National Institute for Research in Tuberculosis between 1999 and 2013. All patients received rifampicin and isoniazid for 6 months reinforced with pyrazinamide and ethambutol in the first 2 months, given thrice-weekly throughout the study along with HAART in one of the groups. Outcomes were categorized and multivariate logistic regression analysis performed to identify risk factors for ARR. Results: The per-protocol results included patients with tuberculosis: 246 HIV-uninfected patients (HIV–TB+), 212 HIV patients not on HAART (non-HAART), and 116 HIV-infected patients on HAART. Median CD4 counts of the latter 2 groups were 150 and 93 cells/μL, respectively, and the median viral loads were 147 000 and 266 000 copies/mL, respectively. Compared with HIV–TB+, the relative risks (RRs) for an unfavorable response in the coinfected, non-HAART and HAART groups were 2.1 (95% confidence interval [CI], 1.7–14.8; P<.0001) and 2.1 (95% CI, .9–5.2; P=.3), whereas for ARR, the RRs were 21.1 (95% CI, 2.6–184; P<.001) and 8.2 (95% CI, .6–104; P=.07), respectively. Conclusions: HIV-infected patients with tuberculosis treated with a thrice-weekly antituberculosis regimen are at a higher risk of ARR, compared with HIV-uninfected patients, in the presence of baseline isoniazid resistance. HAART reduces but does not eliminate the risk of ARR

Algebraic Effect Handlers go Mainstream (Dagstuhl Seminar 18172)

Languages like C#, C++, or JavaScript support complex control flow statements like exception handling, iterators (yield), and even asynchrony (async/await) through special extensions. For exceptions, the runtime needs to be extended with exception handling stack frames. For iterators and asynchrony, the situation is more involved, as the compiler needs to turn regular code into stack restoring state machines. Furthermore, these features need to interact as expected, e.g. finally blocks must not be forgotten in the state machines for iterators. And all of this work needs to be done again for the next control flow abstraction that comes along. Or we can use algebraic effect handlers! This single mechanism generalizes all the control flow abstractions listed above and more, composes freely, has simple operational semantics, and can be efficiently compiled, since there is just one mechanism that needs to be supported well. Handlers allow programmers to keep the code in direct-style, which is easy to reason about, and empower library writers to implement various high-level abstractions without special extensions. The idea of algebraic effects handlers has already been experimented with in the form of small research languages and libraries in several mainstream languages, including OCaml, Haskell, Clojure, and Scala. The next step, and the aim of this seminar, is to seriously consider adoption by mainstream languages including both functional languages such as OCaml or Haskell, as well as languages like JavaScript and the JVM and .NET ecosystems

Algebraic Effect Handlers go Mainstream (Dagstuhl Seminar 18172)

Languages like C#, C++, or JavaScript support complex control flow statements like exception handling, iterators (yield), and even asynchrony (async/await) through special extensions. For exceptions, the runtime needs to be extended with exception handling stack frames. For iterators and asynchrony, the situation is more involved, as the compiler needs to turn regular code into stack restoring state machines. Furthermore, these features need to interact as expected, e.g. finally blocks must not be forgotten in the state machines for iterators. And all of this work needs to be done again for the next control flow abstraction that comes along. Or we can use algebraic effect handlers! This single mechanism generalizes all the control flow abstractions listed above and more, composes freely, has simple operational semantics, and can be efficiently compiled, since there is just one mechanism that needs to be supported well. Handlers allow programmers to keep the code in direct-style, which is easy to reason about, and empower library writers to implement various high-level abstractions without special extensions. The idea of algebraic effects handlers has already been experimented with in the form of small research languages and libraries in several mainstream languages, including OCaml, Haskell, Clojure, and Scala. The next step, and the aim of this seminar, is to seriously consider adoption by mainstream languages including both functional languages such as OCaml or Haskell, as well as languages like JavaScript and the JVM and .NET ecosystems